AWS Config 適合パック (Conformance Packs) で何ができるのか分からなかったので絵を描いて理解してみた

AWS Config の適合パックについて理解するために、AWS Config ルールと修復アクションについておさらいしました。

#図解

#適合パック

#AWS Config

#AWS

千葉幸宏（チバユキ）

2020.05.27

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

コンバンハ、千葉（幸）です。

何かとコンフォーマンスしがちな今日この頃、いかがお過ごしでしょうか。

AWS Config の適合パック（コンフォーマンスパック）というものについて、最近知る機会がありました。適合パックについて、公式ブログでは以下のような説明があります。

適合パックを使用すると、コンプライアンスルールのパッケージを作成することができます。このパッケージはAWS Config ルールと修復アクションの両方を単一のエンティティにまとめたもので、大規模な展開を容易にします。そして、これらを組織全体に展開し、顧客や他のユーザーと共有できます。さらに、適合パックによりコンプライアンス・レポートも簡素化されます。これからは適合パックレベルでのレポートが可能になり、そこから従来通り個別のルールやリソースのレベルへ詳細化していくことも可能です。既存のレポート機能はすべてそのまま機能したままで、異なるチーム、異なるコンプライアンス体制、もしくは異なるガバナンス体制によって管理されたコンプライアンスセットを論理的にグルーピングすることができます。

なるほど。

...つまり　...どういうことだってばよ？

となったので、絵を描いてみることにしました。困ったらとりあえず描きますよね。

AWS Config ルールの絵を描く

適合パックを構成する要素として、AWS Config ルールと修復アクションがあります。まずはここから抑えることにします。

AWSドキュメント

AWS Config ルールを表したのが以下のイメージです。

AWS Config ルールを作成することでリソースに対する設定内容を評価することができます。AWSリソースは評価の結果、Config ルールに準拠しているか否かが定義されます。

例えば自アカウントのS3バケットを対象に「S3バケットがパブリックに書き込み可能な状態になっていないか」を評価するルールを作成すると、各S3バケットに対して評価が行われ、準拠状態にあるS3バケットとそうでないバケットに振り分けられます。

AWS Config ルールは、いくつかの要素から構成されます。

名称
説明
トリガー
ソースルール

名称と説明は特筆すべき点はないので、他の要素を掘り下げます。

AWS Config ルールのトリガー

トリガーは「定期的」「設定変更」の2種類に分類されます。前者は指定した時間ごとに定期的に評価が行われます。後者は指定したリソースに対する設定変更が発生した場合に評価が行われます。リソースの指定の仕方は、先ほどのS3の例に則ると以下のような指定の仕方ができます。

リソースの種類（S3バケット全体）
識別子まで含めたリソース（1つ以上のS3バケットを明示的に指定）
特定のタグがついたリソース

そして、どちらのトリガータイプを指定できるかについては、AWS Config ルールにおける「ソースとなるルール」に影響を受けます。（ややこしいですね。）

指定できるルールには以下2種類があります。

AWS Config マネージドルール
AWS Config カスタムルール

AWS Config マネージドルール

マネージドルールは、評価内容を予めAWSが定義してくれているルールです。

再びS3の例を取ると、S3_BUCKET_PUBLIC_WRITE_PROHIBITEDという識別子のマネージドルールを使用したConfig ルールを作成することで、簡単に評価を行うことができます。

s3-bucket-public-write-prohibited

ドキュメントを確認すると、このマネージドルールはトリガータイプとして「設定変更」がサポートされていることが分かります。

マネージドルールによっては、パラメータとして何かしらの値を渡す必要があるものがあります。定義されているAWS Config マネージドルールの一覧および詳細は、以下を参照してください。

AWS Config マネージドルールのリスト

AWS Config カスタムルール

カスタムルールは、独自に定義した評価内容を Config ルールに設定できるものです。カスタムルールの内容をLambdaファンクションとして作成しておき、 Config ルールにそれを設定することで実現します。Lambdaファンクションの作成時に、トリガータイプ「定期的」「設定変更」それぞれに対応した設計図が用意されているため、それをカスタマイズして作成することもできます。

コードのサンプルは各言語ごとにいくつか用意されているので、こちらも参考にできます。

AWS Config 修復アクションの絵を描く

AWS Config ルールの確認が終わったので、もう一つのキーワード修復アクションを確認します。

AWSドキュメント

イメージは以下です。

修復アクションは、AWS Config ルールに紐づける形で設定します。ルールによる評価の結果「非準拠」になったリソースに対して修復アクション（リソースの設定変更）を行い、「準拠」状態へ遷移させることができます。修復の実行を「自動」で行うか「手動」で行うかを選択可能です。

修復アクションは AWS Systems Manager の Automation ドキュメントによって行われます。 Config ルールと同じように、AWSが管理しているドキュメントと、カスタマーが独自に作成するドキュメントとが選択できます。いずれも、実行には Automation が assume するためのロールが必要となります。

冒頭のS3の例に戻ると、AWS管理の Automation ドキュメントAWS-DisableS3BucketPublicReadWriteを修復アクションとして指定することで、非準拠リソースを修復することができます。

修復アクションを設定する際には、繰り返し回数や失敗率に応じたレート制限を指定したり、ドキュメントによってはパラメータを設定します。

修復アクションの設定・動作イメージとしては以下を参照すると分かりやすいでしょう。ここでは、AWS Config マネージドルールに対してAWS-DisablePublicAccessForSecurityGroupというAWS管理のドキュメントを使用して自動で修復アクションを実行させています。

AWS Config 適合パックの絵を描く

ここまで AWS Config ルールと修復アクションを確認しました。これらは従来から存在するコンポーネントであり、これ自体は新しい考え方ではありません。両者をパッケージ化してひとつのかたまりとして管理できるようになったのが AWS Config 適合パックです。

イメージは以下です。

この図においては適合パックを一つしか表現していませんが、適合パックは一つのエンティティであり、複数作成することができます。適合パックの中心となるのはテンプレートです。 CloudFormation と同じような記法で一つ以上の AWS Config ルール（および必要に応じて修復アクション）を定義し、一括でデプロイすることができます。デプロイされた Config ルールは個別に作成された場合と同様に管理することもできますし、適合パックというグループの中で管理することもできます。

適合パックによるデプロイの裏側では CloudFormation が呼び出されているようです。修復アクションを含める場合の Automation 用のロールや、 AWS Config カスタムルールを使用する場合のLambdaファンクションなどは、ここでのデプロイの対象外となるため、先行して作成しておく必要があります。また、適合パックのデプロイにはサービス用のロールが必要になります。

適合パックという概念が登場する前から、 CloudFormation で AWS Config ルールと修復アクションを作成して管理するということはできました。それをさらにラップ・グルーピングして、適合パックという単位で管理できるようになったのが嬉しい部分だと理解しました。適合パック単位でレポートを作成してS3バケットに対して出力してくれたり、複数リージョンや別アカウントへの横展開がしやすいというメリットがあります。

適合パックの設定イメージは以下エントリを参照すると分かりやすいでしょう。

適合パックは Organizationsとも連携可能なため、以下のような形でマスターアカウント配下のAWSアカウントにデプロイすることができます。このような一元管理にも対応しています。